It is common for applications that are sensitive or applications that manage sensitive data to require user authentication before granting user access to the application or its data. Authentication prevents unauthorized or unknown users from gaining the benefit of the application, attacking the application or attacking or exploiting the data managed by the application. Authentication typically requires a valid password for a userID.
It was known for a web application that authenticates a user to generate a “session cookie”, record the session cookie and send the session cookie to the web browser of the user's computer where it is stored. The session cookie contains an identifier of the session and the application for which the session is effective. The web browser sends the session cookie with subsequent requests to the web application to notify the web application that the user has already been authenticated to the web application in the same session. If the session cookie is sent with a request to the same application that established the session, the application will recognize the session and not again request authentication information from the user. The web browser may also send the session cookie with subsequent requests to different web applications. However, this other web application will not have any record of the session and therefore, will request authentication information from the user to establish a current session with this other web application. If the web browser does not include any session cookie with the request, then this other web application will request authentication information from the user to establish a current session with this other web application. A session cookie expires at the end of the session, and the application that established the session and session cookie will delete or invalidate the identifier for the session.
Some corporations have multiple internal and external websites with web servers running different applications. It was known to require a user, at the start of a session, to separately supply his or her userID and password for each application within the corporation that he or she wants to access. In such a scenario, each application can maintain a list of valid combinations of userID and password or can access such a list from a central directory and compare the list of valid combinations to the combination presented by the requester. In this scenario, the user does not have to authenticate himself or herself for access to every application.
A known single sign-on technique uses a proxy server such as IBM Tivoli Access Manager™ proxy or Computer Associates eTrust SiteMinder™ proxy. The proxy server is interposed between a user computer and all related applications resident on one or more web servers of the same corporation. Upon request by the proxy server, each user supplies authentication information to the proxy server once per session with the proxy server. The same authentication information—userID and password, is valid for all user requests for all related applications during the same user session with the proxy server. The proxy server then manages authentication to the related applications. Users make all requests via the proxy server to access and use the related applications. Thus, when the user requests access to any of the related applications during the same session with the proxy server, the proxy server furnishes the user's authentication information (userID and password) to such application. The proxy server also relays all subsequent requests by the user to the application during the same session with the proxy server. While the foregoing single sign-on technique reduces the authentication burden on the user, it requires a proxy server interposed between all users' workstations and all application server. The proxy server must handle a large volume of user requests and application responses. The proxy server may be “transparent” (sometimes called a “reverse” proxy server), in which case the user and client computer need not be aware of the proxy server. In the case of a transparent proxy server, the client computer addresses the requests to the web application server. However, a domain name server substitutes the address of the proxy server for the user requests so the user requests go directly to the proxy server instead of the web application server. If the proxy server is “visible” (sometimes called a “forward” proxy server), the client computer “knows” of the proxy server and is reconfigured to address web application requests directly to the proxy server instead of the web application server.
Tivoli Federated Identity Manager™ software allows for disparate domains to share identity information from one or many identity providers. Such identity federation strategies require integration into an existing single sign-on domain such as Tivoli Access Manager™, a trust establishment between the service and identity providers, and additional hardware and software components integrated into the existing application hosting environment. In this scenario, the client request flow would be the same as the Tivoli Access Manager™ solution described above, except for the manner in which the proxy authenticates the client's identity and authorizes access to the content in the request. In the above scenario, the proxy authenticates users and gains authorization to a resource for a particular request all within the scope of the local Tivoli Access Manager™ domain. In a Federated Identity Manager architecture, the proxy component of the Tivoli Access Manager™ domain in which the application resides would communicate with a centralized identity provider either in that same domain, or in another Tivoli Access Manager™ domain. This allows disparate Tivoli Access Manager™ domains to act as application service providers, while all authenticating against a centralized identity provider.
U.S. Published Application serial 2003/0105981 by Miller et al. discloses sharing of session information among related applications. According to this technique, when a user initially authenticates himself or herself to one application, the one (authenticating) application sends the authentication information and session information to related applications (in the same or different web server), before the user attempts to access the related applications. The one (authenticating) application also sends a session cookie to the users web browser. The session cookie includes the session identifier and an identification of an application that can validate the session. If the user attempts to access one of the other, related application, the web browser supplies the session cookie, and the other, related application verifies the session cookie with the one (authenticating) application. If the session is valid, then the other, related application will grant the user access to itself without requesting authentication information from the user. While the sharing of session information is effective for single sign-on, the one authenticating application sends authentication information to related applications for which the user may never access.
An object of the present invention is to provide an effective, single sign-on technique for related applications.
Another object of the present invention is to provide an effective single sign-on technique which can be applied to existing applications without making any modifications to these applications.
Another object of the present invention is to provide an effective, single sign-on technique for related applications without requiring a proxy server of the foregoing types.